Duckietown is a robotics educations and outreach effort.

The most tangible goal of the project is to provide a low-cost educational platform for learning autonomy, consisting of the Duckiebots, an autonomous robot, and the Duckietowns, the infrastructure in which the Duckiebots navigate.

However, we focus on the learning experience as a whole, by providing a set of modules teaching plans and other guides, as well as a curated role-play experience.

We have two targets:

1. For instructors, we want to create a “class-in-a-box” that allows to offer a modern and engaging learning experience. Currently, this is feasible at the advanced undergraduate and graduate level, though in the future we would like to present the platform as multi-grade experiences.

2. For self-guided learners, we want to create a “self-learning experience”, that allows to go from zero knowledge of robotics to graduate-level understanding.

In addition, the Duckietown platform has been used as a research platform.

This video is a Duckumentary about the first version of the class, during Spring 2016. The Duckumentary was shot by Chris Welch.

See also this documentary by Red Hat:

The video is at https://vimeo.com/219731087.

If you’d like to know more about the educational experience, [1] present a more formal description of the course design for Duckietown: learning objectives, teaching methods, etc.

The best way to get a sense of how the platform looks is to watch these videos. They show off the capabilities of the platform.

If you would like to know more, the paper [2] describes the Duckiebot and its software. (With 29 authors, we made the record for a robotics conference!)

Can you do it by night?

The video is at https://vimeo.com/152825632.

The original Duckietown class was at MIT in 2016.

The video is at https://vimeo.com/152233002.

The video is at https://vimeo.com/152499589.

The video is at https://vimeo.com/149916365.

Later that year, the Duckietown platform was also used in these classes:

• National Chiao Tung University 2016, Taiwan - Prof. Nick Wang;
• Tsinghua University, People’s Republic of China - Prof. (Samuel) Qing-Shan Jia’s Computer Networks with Applications course;
• Rennselaer Polytechnic Institute 2016 - Prof. John Wen;

In 2017, these four courses will be taught together, with the students interacting among institutions:

• ETH Zürich 2017 - Prof. Emilio Frazzoli, Dr. Andrea Censi;
• University of Montreal, 2017 - Prof. Liam Paull;
• TTI/Chicago 2017 - Prof. Matthew Walter;
• National Chiao Tung University, Taiwan - Prof. Nick Wang’s course;

Furthermore, the Duckietown platform is used also in the following universities:

• Rennselaer Polytechnic Institute (Jeff Trinkle)
• National Chiao Tung University, Taiwan - Prof. Yon-Ping Chen’s Dynamic system simulation and implementation.
• Chosun University, Korea - Prof. Woosuk Sung’s course;
• Petra Christian University, Indonesia - Prof. Resmana Lim’s Mobile Robot Design Course
• National Tainan Normal University, Taiwan - Prof. Jen-Jee Chen’s Vehicle to Everything (V2X) Course;
• Yuan Zhu University, Taiwan - Prof. Kan-Lin Hsiung’s Control course;

Duckietown was created in 2016.

If you are an instructor, please jump to Section 4.2.

If you are a self-guided learner, please jump to Section 4.3.

If you are a company, and interested in working with Duckietown, please jump to Section 4.4.

Currently, Duckietown has the following accounts:

• Github: for source code, and issue tracking;
• Slack: a forum for wide communication;
• Twist: to be used for instructors coordination;
• Google Drive: to be used for instructors coordination, maintaining TODOs, etc;
• Dropbox Folders (part of Andrea’s personal accounts): to be abandoned;
• Vimeo, for storing the videos;
• The duckietown-teaching mailing list, for low-rate communication with instructors;
• We also have a list of addresses, of people signed up on the website, that we didn’t use yet;
• The Facebook page.

If you are an international contributor:

• Sign up on Slack, to keep up with the project.
• (optional) Get Github permissions if you do frequent updates to the repositories.

All the documentation is in the repository duckietown/duckuments.

The documentation is written as a series of small files in Markdown format.

It is then processed by a series of scripts to create this output:

• a publication-quality PDF;
• an online HTML version, split in multiple pages and with comments boxes.

The simplest way to contribute to the documentation is to click any of the “✎” icons next to the headers.

They link to the “edit” page in Github. There, one can make and commit the edits in only a few seconds.

In the multiple-page version, each page also includes a comment box powered by a service called Disqus. This provides a way for people to write comments with a very low barrier. (We would periodically remove the comments.)

In the following, we are going to assume that the documentation system is installed in ~/duckuments. However, it can be installed anywhere.

We are also going to assume that you have setup a Github account with working public keys.

We are also going to assume that you have installed the duckietown/software in ~/duckietown.

$ which python
/home/user/duckuments/deploy/bin/python

Then:

$ cd ~/duckuments
$ make duckuments-dist

This creates the directory duckuments-dist, which contains another checked out copy of the repository, but with the branch gh-pages, which is the branch that is published by Github using the “Github Pages” mechanism.

~/duckuments/.git
~/duckuments/duckuments-dist/.git

To compile the docs, run make clean compile:

$ make clean compile

To see the result, open the file

./duckuments-dist/master/duckiebook/index.html

This is the workflow:

1. Edit the Markdown in the master branch of the duckuments repository.
2. Run make compile to make sure it compiles.
3. Commit the Markdown and push on the master branch.

Done. A bot will redo the compilation and push the changes in the gh-pages branch.

Step 2 is there so you know that the bot will not encounter errors.

To deploy the documentation, jump into the DUCKUMENTS/duckuments-dist directory.

Run the command git branch. If the out does not say that you are on the branch gh-pages, then one of the steps before was done incorrectly.

$ cd $DUCKUMENTS/duckuments-dist
$ git branch
...
* gh-pages
...

Now, after triple checking that you are in the gh-pages branch, you can use git status to see the files that were added or modified, and simply use git add, git commit and git push to push the files to Github.

The Duckiebook is written in a Markdown dialect.

You can use $\LaTeX$ math, environment, and references. For example, take a look at

$$ x^2 = \int_0^t f(\tau)\ \text{d}\tau $$

or refer to Proposition 1.

The above was written as in Listing 1.

You can use $\LaTeX$ math, environment, and references.
For example, take a look at

\[
    x^2 = \int_0^t f(\tau)\ \text{d}\tau
\]

or refer to [](#prop:example).

\begin{proposition}[Proposition example]\label{prop:example}
This is an example proposition: $2x = x + x$.
\end{proposition}

For the LaTeX environments to work properly you must add a \label declaration inside. Moreover, the label must have a prefix that is adequate to the environment. For example, for a proposition, you must insert \label{prop:name} inside.

The following table shows the list of the LaTeX environments supported and the label prefix that they need.

Examples of all environments follow.

<div id='def:lorem' class="definition latex_env" markdown="1">Lorem</div>

<div id='prop:lorem' class="proposition latex_env" markdown="1">Lorem</div>

<div id='rem:lorem' class="remark latex_env" markdown="1">Lorem</div>

<div id='prob:lorem' class="problem latex_env" markdown="1">Lorem</div>

<div id='exa:lorem' class="example latex_env" markdown="1">Lorem</div>

<div id='thm:lorem' class="theorem latex_env" markdown="1">Lorem</div>

<div id='lem:lorem' class="lemma latex_env" markdown="1">Lorem</div>

I can also refer to all of them:
[](#def:lorem),
[](#prop:lorem),
[](#rem:lorem),
[](#prob:lorem),
[](#exa:lorem),
[](#thm:lorem),
[](#lem:lorem).

We can refer to equations, such as \eqref{eq:one}:

\begin{equation} 2a = a + a \label{eq:one}\tag{1} \end{equation}

This uses align and contains \eqref{eq:two} and \eqref{eq:three}.

\begin{align} a &= b \label{eq:two}\tag{2} \\ &= c \label{eq:three}\tag{3} \end{align}

We can refer to equations, such as \eqref{eq:one}:

\begin{equation}
    2a = a + a          \label{eq:one}
\end{equation}

This uses `align` and contains  \eqref{eq:two} and \eqref{eq:three}.

\begin{align}
    a &= b       \label{eq:two} \\
      &= c       \label{eq:three}
\end{align}

Note that referring to the equations is done using the syntax \eqref{eq:name}, rather than [](#eq:name).

The LaTeX symbols definitions are in a file called docs/symbols.tex.

Put all definitions there; if they are centralized it is easier to check that they are coherent.

Use the syntax “![name]” for describing the variables in the code.

$ ssh robot name.local

For example, to obtain:

    $ ssh ![robot name].local

Make sure to quote (with 4 spaces) all command lines. Otherwise, the dollar symbol confuses the LaTeX interpreter.

Use the string $ to write the dollar symbol $, otherwise it gets confused with LaTeX math materials. Also notice that you should probably use “USD” to refer to U.S. dollars.

Other symbols to escape are shown in Table 2.

Use the kbd element for keystrokes.

Press <kbd>a</kbd> then <kbd>Ctrl</kbd>-<kbd>C</kbd>.

For any element, adding an attribute called figure-id with value fig:figure ID or tab:table ID will create a figure that wraps the element.

For example:

<div figure-id="fig:figure ID">
    figure content
</div>

It will create HMTL of the form:

<div id='fig:code-wrap' class='generated-figure-wrap'>
    <figure id='fig:figure ID' class='generated-figure'>
        <div>
            figure content
        </div>
    </figure>
</div>

To add a caption, add an attribute figure-caption:

<div figure-id="fig:figure ID" figure-caption="This is my caption">
    figure content
</div>

Alternatively, you can put anywhere an element figcaption with ID figure id:caption:

<element figure-id="fig:figure ID">
    figure content
</element>

<figcaption id='fig:figure ID:caption'>
    This the caption figure.
</figcaption>

To refer to the figure, use an empty link:

Please see [](#fig:figure ID).

The code will put a reference to “Figure XX”.

You can also create subfigures, using the following syntax.

<div figure-id="fig:big">
    <figcaption>Caption of big figure</figcaption>

    <div figure-id="subfig:first">
        <figcaption>Caption 1</figcaption>
        <p>Content of first subfig</p>
    </div>

    <div figure-id="subfig:second">
        <figcaption>Caption 2</figcaption>
        <p>Content of second subfig</p>
    </div>
</div>

The shortcuts col2, col3, col4, col5 are expanded in tables with 2, 3, 4 or 5 columns.

The following code:

<col2 figure-id="tab:mytable" figure-caption="My table">
    <span>A</span>
    <span>B</span>
    <span>C</span>
    <span>D</span>
</col2>

gives the following result:

It is possible to embed Vimeo videos in the documentation.

This is the syntax:

<dtvideo src="vimeo:vimeo ID"/>

For example, this code:

<div figure-id="fig:example-embed">
    <figcaption>Cool Duckietown by night</figcaption>
    <dtvideo src="vimeo:152825632"/>
</div>

produces this result:

The video is at https://vimeo.com/152825632.

Depending on the output media, the result will change:

• On the online book, the result is that a player is embedded.
• On the e-book version, the result is that a thumbnail is produced, with a link to the video;
• On the dead-tree version, a thumbnail is produced with a QR code linking to the video (TODO).

You need to have installed bibtex2html.

The system supports Bibtex files.

Place *.bib files anywhere in the directory.

Then you can refer to them using the syntax:

[](#bib:bibtex ID)

For example:

Please see [](#bib:siciliano07handbook).

Will result in:

Please see [3].

If a file contains the tag move-here, the fragment pointed by the src attribute is moved at the place of the tag.

This is used for autogenerated documentation.

Syntax:

# Node `node`

<move-here src='#package-node-autogenerated'>

You can insert comments using the HTML syntax for comments: any text between “<!–” and “–>” is ignored.

# My section

<!-- this text is ignored -->

Let's start by...

The system supports parsing of some special paragraphs.

Note that some of these might be redundant.

For now, documenting what is implemented.

For these, note the rules:

• You must include markdown="1".
• There must be an empty line after the first div and before the closing /div.

You can refer to files in the repository by using:

See [this file](github:org=org,repo=repo,path=path,branch=branch).

The available keys are:

• org (required): organization name (e.g. duckietown);
• repo (required): repository name (e.g. Software);
• path (required): the filename. Can be just the file name or also include directories;
• branch (optional) the repository branch; defaults to master;

For example, you can refer to the file pkg_name/src/subscriber_node.py by using the following syntax:

See [this file](github:org=duckietown,repo=Software,path=pkg_name/src/subscriber_node.py)

You can also refer to a particular line:

This is done using the following parameters:

• from_text (optional): reference the first line containing the text;
• from_line (optional): reference the line by number;

For example, you can refer to the line containing “Initialize” of pkg_name/src/subscriber_node.py by using the following syntax:

For example, you can refer to [the line containing "Initialize"][link2]
of `pkg_name/src/subscriber_node.py` by using the following syntax:

[link2]: github:org=duckietown,repo=Software,path=pkg_name/src/subscriber_node.py,from_text=Initialize

You can also reference a range of lines, using the parameters:

• to_text (optional): references the final line, by text;
• to_line (optional): references the final line, by number.

You cannot give from_text and from_line at the same time. You cannot give a to_... without the from_....

For example, this link refers to a range of lines: click it to see how Github highlights the lines from “Initialize” to “spin”.

This is the source of the previous paragraph:

For example, [this link refers to a range of lines][interval]: click it to see how Github highlights the lines from "Initialize" to "spin".

[interval]: github:org=duckietown,repo=Software,path=pkg_name/src/subscriber_node.py,from_text=Initialize,to_text=spin

In addition to referencing the files, you can also copy the contents of a file inside the documentation.

This is done by using the tag display-file.

For example, you can put a copy of pkg_name/src/subscriber_node.py using:

<display-file src="github:org=duckietown,repo=Software,path=pkg_name/src/subscriber_node.py"/>

and the result is the following automatically generated listing:

#!/usr/bin/env python
import rospy
from std_msgs.msg import String #Imports msg

# Define callback function
def callback(msg):
    rospy.loginfo("I heard: %s" %(msg.data))

# Initialize the node with rospy
rospy.init_node('subscriber_node', anonymous=False)
# Create subscriber
subscriber = rospy.Subscriber("topic", String, callback)

rospy.spin() #Keeps the script for exiting

If you use the from_text and to_text (or from_line and to_line), you can actually display part of a file. For example:

<display-file src="github:org=duckietown,repo=Software,path=pkg_name/src/subscriber_node.py,from_text=Initialize,to_text=spin"/>

creates the following automatically generated listing:

# Initialize the node with rospy
rospy.init_node('subscriber_node', anonymous=False)
# Create subscriber
subscriber = rospy.Subscriber("topic", String, callback)

rospy.spin() #Keeps the script for exiting

The following holds for all technical writing.

• The documentation is written in correct English.

• Do not say “should” when you mean “must”. “Must” and “should” have precise meanings and they are not interchangeable. These meanings are explained in this document.

• “Please” is unnecessary in technical documentation.

“Please remove the SD card.”

“Remove the SD card”.

• Do not use colloquialisms or abbreviations.

“The pwd is ubuntu.”

“The password is ubuntu.”

“To create a ROS pkg…”

“To create a ROS package…”

• Python is capitalized when used as a name.

“If you are using python…”

“If you are using Python…”

• Do not use emojis.

• Do not use ALL CAPS.

• Make infrequent use of bold statements.

• Do not use exclamation points.

• It’s ok to use “it’s” instead of “it is”, “can’t” instead of “cannot”, etc.

• All the filenames and commands must be enclosed in code blocks using Markdown backticks.

“Edit the ~/.ssh/config file using vi.”

“Edit the ~/.ssh/config file using vi.”

• Ctrl-C, ssh etc. are not verbs.

“Ctrl-C from the command line”.

“Use Ctrl-C from the command line”.

• Subtle humor and puns about duckies are encouraged.

Use either “laptop” or “duckiebot” (not capitalized, as a hostname) as the prefix for the command line.

For example, for a command that is supposed to run on the laptop, use:

laptop $ cd ~/duckietown

It will become:

laptop $ cd ~/duckietown

For a command that must run on the Duckiebot, use:

duckiebot $ cd ~/duckietown

It will become:

duckiebot $ cd ~/duckietown

If the command is supposed to be run on both, omit the hostname:

$ cd ~/duckietown

• “Duckiebot” is always capitalized.

• Use “Raspberry Pi”, not “PI”, “raspi”, etc.

• These are other words frequently misspelled:

  5 GHz WiFi

When the user must edit a file, just say: “edit /this/file”.

Writing down the command line for editing, like the following:

$ vi /this/file

is too much detail.

(If people need to be told how to edit a file, Duckietown is too advanced for them.)

Write the documentation as if every step succeeds.

Then, at the end, make a “Troubleshooting” section.

Organize the troubleshooting section as a list of symptom/resolution.

The following is an example of a troubleshooting section.

Each atom has the following properties:

• An ID (alphanumeric + - and ‘_’). The ID is used for cross-referencing. It is the same in all languages.
• A type, as above.

There might be different versions of each atom. This is used primarily for dealing with translations of texts, different representations of the same image, Powerpoint vs Keynote, etc.

A version is a tuple of attributes.

The attributes are:

• Language: A language code, such as en-US (default), zh-CN, etc.

• Mime type: a MIME type.

Each atom version has:

• A status value: one of draft, beta, ready, to-update (Table 7).
• A human-readable title.
• A human-readable summary (1 short paragraph).

For the text-like resources, they are described in Markdown files.

The name of the file does not matter.

All files are encoded in UTF-8.

Each file starts with a H1 header. The contents is the title.

The header has the following attributes:

1. The ID. ({#ID})
2. The language is given by an attribute lang ({lang=en-US}).
3. The type is given by an attribute type ({type=demo}).
4. The status is given by an attribute status ({status=draft}).

Here is an example of a header with all the attributes:

# Odometry calibration {#odometry-calibration lang=en-US type='text/theory' status=ready}

This first paragraph will be used as the "summary" for this text.

And this is how the Italian translation would look like:

# Calibrazione dell'odometria {#odometry-calibration lang=it type='text/theory' status=draft}

Questo paragrafo sarà usato come un sommario del testo.

In the text, you describe the semantic graph using tags and IDs.

In Markdown, you can give IDs to sections using the syntax:

# Setup step 1  {#setup-step1}

This is the first setup step.

Then, when you write the second step, you can add a a semantic edge using the following.

# Setup step 2  {#setup-step2}

This is the second setup step.

Requires: You have completed the first step in [](#setup-step1).

The following table describes the syntax for the different types of semantic links:

Requires: You need to have done [](#setup-step).

Recommended: It is better if you have setup Wifi as in [](#setup-wifi).

Reference: For more information about rostopic, see [](#rostopic).

See also: If you are interested in feature detection, you might want to learn about [SIFT](#SIFT).

Translations are organized file-by-file.

For every file name.md, name the translated file name.language code.md, where the language code is one of the standard codes, and put it in the same directory.

For example, these could be a set of files, including a Chinese (simplified), italian, and Spanish translation:

representations.md
representations.zh-CN.md
representations.it.md
representations.es.md

The reason is that in this way you can check automatically from Git whether representations.zh-CN.md is up to date or representations.md has been modified since.

Here are some considerations for the writers of the original version, to make the translators’ job easier.

It is better to keep files smallish so that (1) the translation tasks can feel approachable by translators; (2) it is easier for the system to reason about the files.

Name all the headers with short, easy identifiers, and never change them.

All files are assumed to be encoded in UTF-8.

The header IDs should not be translated and should remain exactly the same. This will allow keeping track of the different translations.

For example, if this is the original version:

# Robot uprising {#robot-uprising}

Hopefully it will never happen.

Then the translated version should be:

# La rivolta dei robot {#robot-uprising}

Speriamo che non succeda.

• Configuration C0: Only camera and motors.

• Configuration C0+w: C0, plus an additional wireless adapter.

• Configuration C0+j: C0, plus an additional wireless joypad for remote control.

• Configuration C0+d: C0, plus an additional USB drive.

• Configuration C1: C0+wjd, plus LEDs and bumpers.

To begin with, find a male USB-A to anything cable.

If you have purchased the suggested components listed in Chapter 12, you can use the longer USB cable contained inside the battery package (Figure 29), which will be used as an example in these instructions.

Put the shorter cable back in the box, and open the longer cable (Figure 30)

Take the scissors and cut it (Figure 31) at the desired length from the USB-A port.

The cut will look like in Figure 32.

Paying attention not to get hurt, strip the external white plastic. A way to do so without damaging the wires is shown in Figure 33.

After removing the external plastic, you will see four wires: black, green, white and red (Figure 34).

Once the bottom part of the external cable is removed, you will have isolated the four wires (Figure 35).

Once you have isolated the wires, strip them, and use the scissors to cut off the data wires (green and white, central positions) (Figure 36).

If you are not using the suggested cable, or want to verify which are the data and power wires, continue reading.

If you are using the USB-A cable from the suggested battery pack, black and red are the power wires and green and white are instead for data.

If you are using a different USB cable, or are curious to verify that black and red actually are the power cables, take a multimeter and continue reading.

Plug the USB port inside a power source, e.g., the Duckiebot’s battery. You can use some scotch tape to keep the cable from moving while probing the different pairs of wires with a multimeter. The voltage across the pair of power cables will be roughly twice the voltage between a power and data cable. The pair of data cables will have no voltage differential across them. If you are using the suggested Duckiebot battery as power source, you will measure around 5V across the power cables (Figure 37).

You are now ready to secure the power wires to the DC motor HAT power pins. To do so though, you need to have soldered the boards first. If you have not done so yet, read Chapter 13.

If you have soldered the boards already, you may test correct functionality of the newly crafted cable. Connect the battery with the DC motor HAT by making sure you plug the black wire in the pin labeled with a minus: - and the red wire to the plus: + (Figure 38).

If the green LED turns on, the DC motor HAT is receving power.

Download the image from the page

https://ubuntu-mate.org/download/

The file we are looking for is:

filename: ubuntu-mate-16.04.2-desktop-armhf-raspberry-pi.img.xz
    size: 1.2 GB
  SHA256: dc3afcad68a5de3ba683dc30d2093a3b5b3cd6b2c16c0b5de8d50fede78f75c2

After download, run the command sha256sum to make sure you have the right version:

laptop $ sha256sum ubuntu-mate-16.04.2-desktop-armhf-raspberry-pi.img.xz
dc3afcad68a5de3ba683dc30d2093a3b5b3cd6b2c16c0b5de8d50fede78f75c2

If the string does not correspond exactly, your download was corrupted. Delete the file and try again.

Then decompress using the command xz:

laptop $ xz -d ubuntu-mate-16.04.2-desktop-armhf-raspberry-pi.img.xz

Next, burn the image on to the SD card.

The Raspberry Pi is not accessible by SSH by default.

Run raspi-config:

duckiebot $ sudo raspi-config

choose “3. Interfacing Options”, and enable SSH,

We need to enable the camera and the I2C bus.

choose “3. Interfacing Options”, and enable camera, and I2C.

Also disable the graphical boot

Install these packages.

Etckeeper:

duckiebot $ sudo apt install etckeeper

Editors / shells:

duckiebot $ sudo apt install -y vim emacs byobu zsh

Git:

duckiebot $ sudo apt install -y git git-extras

Other:

duckiebot $ sudo apt install htop atop nethogs iftop
duckiebot $ sudo apt install aptitude apt-file

Development:

duckiebot $ sudo apt install -y build-essential libblas-dev liblapack-dev libatlas-base-dev gfortran libyaml-cpp-dev

Python:

duckiebot $ sudo apt install -y python-dev ipython python-sklearn python-smbus
duckiebot $ sudo apt install -y python-termcolor
duckiebot $ sudo pip install scipy --upgrade

I2C:

duckiebot $ sudo apt install -y i2c-tools

First, mark the kernel packages as not upgradeable:

$ sudo apt-mark hold raspberrypi-kernel raspberrypi-kernel-headers
raspberrypi-kernel set on hold.
raspberrypi-kernel-headers set on hold

Then, download and install the Edimax driver from this repository.

$ git clone git@github.com:duckietown/rtl8822bu.git
$ cd rtl8822bu
$ make
$ sudo make install

Install ROS.

This is the old version.

There are two files that are important to edit.

The file /etc/network/interfaces should look like this:

# interfaces(5) file used by ifup(8) and ifdown(8)
# Include files from /etc/network/interfaces.d:
#source-directory /etc/network/interfaces.d

auto wlan0

# The loopback network interface
auto lo
iface lo inet loopback

# Wireless network interface
allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

The file /etc/wpa_supplicant/wpa_supplicant.conf should look like this:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

network={
ssid="duckietown"
psk="quackquack"
proto=RSN
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
}
network={
   key_mgmt=NONE
}

The files that describe the network configuration are in the directory

/etc/NetworkManager/system-connections/

This is the contents of the connection file duckietown, which describes how to connect to the duckietown wireless network: